Little mice squeek to much - feedback on some of the coding issues..

What kind of people work on these Projects?

I find it rather disturbing when, rather than discuss the various merit's of trades off's that where made when making the decisions, there is a tendency to attack the messenger. While you may regard your project as 'Under attack', at the same time, it's a good way to find out how sensible and rational are the members of that project..

What's all this wingeing all about?

Why do I bother writing these blog post, (I often ask myself). Well my major concern is simple, Maintaining code, and making sure someone else can maintain code written by me, or others.. This is what takes up the majority of developers time. And time is the only thing we can't get a refund on... Unless we are on pay by the hour contracts, getting things done quicker either makes us richer, we can charge more for less... or let's us get on with those fun projects.

At the office I work in, we always joke, without Microsoft, we would be broke.. We would never get much support work (our desktop linux installations can run for years without many support calls!). But our desktop Windows boxes generate great income.. Loads of fixes, lots of things always going wrong. Great from a charge by the hour fixing angle, but lousy from a life enjoyment perspective.... Managing illogical or poorly thought out code often has that same feeling...

Anyway back to some of the more amusing quotes (from comments and the referrers..)

"Seems like this guy just doesn't like frameworks"

mmh, not really, I guess it depends on how the "framework" presents itself.

• "we recommend you use this tiny framework with these classes, but we are not forcing you to., it should work with just about anything..."
• "use practically all our classes, otherwise the whole thing will fall apart".

It goes back to Unix's classic ideology, (which I'm sure this quote is wrongl). "Dont do to much, but do what you know well.. " or something about "A combination of small parts"

There are a number of reasons why this works and I'm sure google can find a better list of why.

- What happens in 4 years when the maintainers/developers/designers left, moved on. Can someone else take over the whole project? and run it. The smaller the project, the easier this is to do.

- If one area's design concept sucked, redoing a small part is easier than redoing the whole lot.

This is where PEAR's small packages really shine, and Large hyper dependent Frameworks tend to look risky very quickly.

ORM's suck or not

Well, like all code using it in the wrong place can be a bad idea. Generally for PHP ORM's are quite efficient, as the majority of the work in most application is just searching/fetching/updating etc. which ORM's shine atog. For more complex stuff like data analysis, good old SQL is far more efficient. And for a flat file website, ORM is a bit of an overkill.

There are a few ready made ones out there (two in PEAR), which is why when you see a framework re-inventing it's own rather than just cherry picking the best, you know the authors just may be missing the boat. I can vouch from experience here, Maintaining an ORM is no small task, let along trying to maintain, document and answer the occasional support question

"light filtering on incoming data"

While agreeing with the issue that raw PHP output is dangerous, Some one mentioned "light filtering". I've seen this light filtering approach on the PEAR web site, it's a pig's ear. It has resulted in the situation where you have no idea if or where data has been filtered or escaped. And code that is exploitable or over-escaped.   - I love keeping things simple here, escape when and where it's needed, and only there. - at the template output

- when you build your SQL in the ORM? (another hidden benefit)

- when it's being formated for transport (eg. JSON)

- when you format text to display in ExtJS (which is where the security hacks help)

The rest of the time, the data is available nude, raw and unformated as it truely deserves to be...

"Javascript based Apps are a disaster waiting to happen"

I'm not quite sure I agree with all this issues here, Yes, just downloading and starting to write code with projects like ExtJS, you will quickly run into quite a few issues. Slow loading times, Browser incompatibilities etc. But most of this are quite easy to fix, Code compacting and bundling all the JS code into one file solves the initial Load isssues (dont have 25 .js includes at the top of you html.. the users will get bored waiting for the page to load).

Browser Incompatibility, ExtJS, and most of the others have pretty good coverage, for all browsers, along with helping solve most of the remaining compatibility issues for you.

The only really big Issue I always hit, is IE's non-standard Javascript syntax to be the issue (comma added or missing in arrays/object definitions). Which is prety simple to spot, most of the time..

As for slow loading of data, I have not really see any difference from loading data as HTML, as to loading into JSON. Saying that, I would not use ExtJS to load the body of this blog post, but it might be a good replacement for the Comments at the bottom... - But ExtJS really excels when used for online applications. Filling in timesheets, Managing Contacts etc.

This site pretty borked...

Yeah.. Normally when I write about really interesting stuff, (Javascript interpreters) no-one comments, oh well. It didnt take long to find the code to fix the URL and remove the silly [x] not working yet boxes... - Since the code was nice and clean.....